Remarks 

In the final Office Action mailed December 3, 2003: 

1. Claims 1-3, 5-7, 9-22 and 24-32 were rejected under 35 U.S.C. § 103(a) in view 
of U.S. Patent No. 5,844,890 (Delp); and 

2. Claim 8 was rejected xrnder 35 U.S.C. § 103(a) in view of Delp and U.S. Patent 
No. 5,732,094 (Petersen). 

I. Deb gj.S. Patent No. 5,844,890) 

Delp is intended to describe "a method for scheduling cell transmissions that provides 
proportional use of available network bandwidth" (column 1, lines 22-24). Because Delp is 
concerned with proportional use of network bandwidth, and does not allow dynamic adjustment 
of the amount of data a channel can transmit, it caimot make obvious the claimed embodiments 
of Applicant's invention. 

A, Delp Does Not Compare an Amount of Data Sent to a Threshold, and Cannot 
Send more than the Threshold 

Delp schedules data for transmission based on slots in a timing wheel (column 5, lines 

62-66). The Examiner has stated that Delp teaches placing a limit or weight corresponding to a 

threshold time that corresponds to a threshold amount of data, wherein the threshold time 

corresponds to time slots in a timing wheel (first full paragraph of page 3 of the final office 

action). 

It is therefore understood by Applicants that the Examiner is asserting that Delp 
associates a threshold amount of data with a queue, wherein the threshold data amoimt is equal to 
the time period represented by the time slot(s) assigned to the queue, multiplied by the bit rate. 

It is therefore impossible for Delp to exceed that threshold amount of data. During each 
turn or slot, the cell scheduler 102 in Delp can only schedule an amount of data corresponding to 
the slot assigned to a given queue (i.e., the "threshold amount"), no more. 

Thus, there is no comparison of data amounts in Delp; doing so would be a waste of time. 
The scheduler looks in the current frame of a timing wheel, finds the active, assigned queue, and 
schedules data from the queue. The scheduler cannot and does not adjust the size of a slot or 
continue servicing a queue after its current slot has ended and the next slot has begun. Each 
queue's turn, or each slot, results in a set amount of data being transmitted, no more. 
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In one or more claimed embodiments of Applicant's invention (e.g., claims 1, 1 1, 24, 32), 
more than the threshold amount of data may be scheduled during a memory's turn. Delp cannot 
do this. 

The Examiner cited to FIG. 7 and column 8, lines 45-67 of Delp as teaching this aspect of 
Applicants' invention. "FIG. 7 is a flow chart illustrating sequential operations of the cell 
scheduler of the preferred embodiment of FIG. 1 to determine a move to a next time slof 
(column 4, lines 30-32; emphasis added). Thus, FIG. 7 and the accompanying text deal with 
selecting a next time slot, not determining whether an amount of data scheduled for transmission 
exceeds a threshold amount. The accompanying text says nothing about an amount of data that 
has been transmitted or scheduled for transmission : 
700: start; 

702: search the current frame for an active bit that is on; 

704: if no active bits that are on are found, a next frame is read; 

706: if an active bit that is on is found, move to the corresponding slot; 

708: done; 

710: check whether a slow wheel boundary is crossed; 
712: if a slow wheel boundary was crossed, start slow wheel processing as 
shovm in FIG. 7A. 

Applicants can find no mention of anything similar to the "determining" actions recited in claims 
1, 11, 24 and 32 of the application. 

B. Delp does not Decrease a Threshold Amount of Data when a Previous 
Amount of Data Scheduled for Transmission Exceeds the Threshold 

Delp schedules data for transmission based on slots in a timing wheel (column 5, lines 

62-66). The timing wheel slots apparently allow only a fixed amount of data to be scheduled. 

Therefore, each time a queue is scheduled, it is for a set amoimt of data. This is logical, as Delp 

is designed to provide "proportional use of available network bandwidth" (column 5, lines 14- 

15) for multimedia applications (column 1, lines 28-33), which are characterized by steady 

streams of data. 

The cumulative amount of data being sent for a given queue is apparently controlled by 
the frequency with which the queue is assigned to a slot (e.g., FIGs. 10-13; column 11, lines 1- 
27). For example, the invention is described in the context of an ATM cell scheduler (column 5, 
lines 7-12), which requires fixed size cells (column 1, lines 54-55). 

Because Delp uses fixed size time slots, as described in Section I.B, Delp cannot 
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schedule more data from a queue than one time slot will accommodate. Consequently, Delp 
would not and cannot decrease a threshold amoimt of data to be scheduled for transmission 
during a subsequent servicing turn. 

In the final office action, the Examiner stated that "by teaching adjusting the allotted time 
for transmission, Delp teaches adjusting the amount of data scheduled by determining an 
adjusted allotted time having an established bit rate." Applicants respectfiiUy disagree and are 
unsure how Delp is being interpreted as "teaching adjusting the allotted time," Delp may 
schedule data for transmission at different times (i.e., by using different time slots), but each slot 
allows the same amovmt of data to be transmitted , no more. 

In particular, Delp services a given queue during its assigned slot, and then schedules a 
next slot based on appropriate parameters (e.g., column 6, lines 43-53). Delp apparently cannot 
and does not adjust the size of slots in a timing wheel or the amount of data scheduled for 
transmission during a slot. No mention of decreasing the size of a slot was located by 
Applicants. 

Even if Delp could be interpreted as altering the frequency with which a queue is 
scheduled, Delp doesn't do so after determining whether an amount of data scheduled for 
transmission was greater than a threshold associated with the queue from which the data was 
scheduled. 

C. Delp does not Maintain a Deficit if Too Much Data is Scheduled or Sent 

As described above, Delp cannot send or schedule more than a threshold amount of data 
- the amount associated with one timing slot. Therefore, Delp need not and cannot reduce a 
subsequent amount of data subsequently sent or scheduled. And, Delp need not and does not 
maintain a deficit for a queue, to indicate how much more than the threshold was sent or 
scheduled for a particular queue. 

D. Delp does not Monitor an Amount of Data Retrieved During Servicing 

Delp does not appear to include an entity comparable to the arbiter of claim 25, which 
may be responsible for making the determination described in section LB. 

For this element, the Examiner cited block 720 of FIG. 7 A, which is described at column 
9, lines 12-18. "FIG. 7 A is a flow chart illustrating exemplary steps for processing the slow 
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timing wheel data of FIG. 7" (column 4, lines 33-34; emphasis added). Decision block 720 asks 
whether any entries remain in the current segment of the slow timing wheel. This is a Boolean 
test , and is answered yes or no. There is no need for, or mention of, monitoring the amount of 
data retrieved from a memory. In particular, the answer to block 720 would be the same 
regardless of whether the current segment was fiiU of entries or contained but one entry. 

And, the number of entries in the segment is merely a precursor to moving the associated 
LCD to a new location on either the fast or slow timing wheel. This does not involve the 
retrieval of any data from the LCD, 

E. Delp Does Not Use Dynamic Weights Associated with Memories for 
Controlling How Much Data is Scheduled or Sent 

In Delp, data cells of a data stream are stored in queues, for which target transmission 

times are calculated using parameters associated with the stream's logical channel (column 3, 

lines 3 1-34). Queues are assigned to appropriate time slots in the timing wheels, to attempt to 

meet the target transmission times (column 3, lines 34-37). Each slot apparently allows a single 

transmission from whichever data cell queue is assigned to the slot and is active when the slot 

becomes the current slot. All slots are apparently equal in the amount of data cells they allow to 

be scheduled. 

A claimed embodiment of Applicant's invention (e.g., claim 1) employs a plurality of 
memories having dynamic weights conesponding to threshold amounts of data permitted to be 
scheduled during each memory's turn. 

The Examiner states that "by placing a limit on the amount of time for a timing wheel, 
Delp provides means for maintaining a dynamic weight" for the data cell queues, "wherein the 
weight corresponds to a threshold amount of data according to the time and the established bit 
rate" (first full paragraph on page 3 of final office action). 

However, each slot apparently allows the same amount of data to be transmitted, and 
does not change - thus, Delp does not employ dynamic weights, if it uses any weights at all. 
Further, Delp does not associate any threshold timing, weight or limit with the Logical Channel 
Descriptors (LCDs) or the queues in which data packets are stored. The LCDs simply hold data 
until the timing wheels reach slots for which an LCD has been scheduled. 

If it is the Examiner's contention that Delp's timing wheels have the specified threshold 
times associated with them, this conflicts with other claim rejections. In particular, the Examiner 
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states in paragraph 4 of the final office action that the "plurality of memories" recited in claim 1 
corresponds to Delp's "queue of data descriptors" or LCDs. But claim 1 of the application 
specifies that it is the plurality of memories that have dynamic weights corresponding to 
threshold amounts of data, 

11. Selected Claims 

A, Claims 1-3, 5-10, 32 

As described above, Delp does not teach or suggest the following elements of claims 1 

and 32: 

maintaining a dynamic weight for each of said plurality of 
memories, wherein each said dynamic weight corresponds to a threshold 
amount of data associated with said predetermined priority; 

retrieving data described by said received descriptor, 
wherein the amount of retrieved data may exceed said threshold 
amount; 

determining whether an amount of data scheduled during 
said servicing for transmission via said communication link 
exceeds said threshold amount of data corresponding to said 
dynamic weight for said serviced memory; 

... and 

if said amount of data scheduled for transmission exceeds 
said threshold amount of data, decreasing said threshold for a next 
servicing of said serviced memory. 

Regarding the use of dynamic weights, in the final office action the Examiner stated that 

it is the Examiner's contention that by placing a limit on the 
amount of time for a timing wheel, Delp provides means for maintaining a 
dynamic weight for the memories wherein the weight corresponds to a 
threshold amoimt of data according to the time and the established bit rate. 

Applicant is unsure what "placing a limit on the amount of time for a timing wheel" means. The 
timing wheels of Delp apparently cycle continuously, and the "time" measured by a timing 
wheel is measured in slots, not conventional time units (i.e., seconds, minutes). If it is the length 
of time associated with one time slot that is meant by this phrase, then the phrase is incorrect, 
because Delp does not alter the size of slots in a timing wheel (i.e., they are not dynamic in size). 
Even if it is the number of slots to which a queue is assigned that is considered to be dynamic, 
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Applicants still disagree with the contention, Delp only schedules one slot at a time . Each time 
a queue is serviced during a slot, its next slot is assigned (e.g., column 6, lines 26-41 ; column 6, 
lines 47-53). And, the maimer in which one slot is processed (e.g., how much data is scheduled) 
is not affected by how a previous slot was processed. 



B. Claims 11-22,24 

The rejections of claims 1 1 and 24 are traversed for the reasons stated in sections I and 

II. A above. In particular, Delp does not teach or suggest the following elements: 

storing in a first memory a first set of descriptors associated with 
data having a first priority, wherein said first memory has a first dynamic 
weight corresponding to a first threshold amount of data; 

determining whether an amount of first priority data 
exceeding said first threshold has, during said first servicing tum, 
been scheduled for transmission; and 

if said first threshold has been exceeded, maintaining a first deficit 
to determine how much less than said first threshold of data may be 
scheduled during a subsequent servicing turn of said first memory, 
wherein said first deficit is initially proportional to said excess. 

The "determining whether an amount of first priority data" element of claims 1 1 and 24 
clearly indicates that an amount of data exceeding the first threshold may be sent during a 
servicing tum. 

In addition, claims 1 1 and 24 recite the following: 

in a first servicing tum of said first memory: 
determining whether one of said first weight and said second 
weight has changed; 

When Delp is scheduling data from one LCD during a slot, it does not consider any other 
LCDs. Therefore, even if Delp could be interpreted as teaching the use of dynamic weights 
corresponding to threshold amounts of data, Delp does not look at one LCD's parameters when 
servicing another. 

C. Claims 25-31 

The rejections of claims 25-31 are traversed for the reasons stated above in sections I and 

II.A. 
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Claim 28 recites determining whether an amount of data that was scheduled exceed a 
preferred amount (e.g., a threshold). As described above, Delp does not make such a test 
because each time a queue is scheduled, the same amount of data is scheduled (i.e., one time 
slot). 

Claims 29-30 recite the use of a deficit to indicate how much to reduce the amount of 
data sent in a subsequent servicing turn. Delp does not appear to maintain a running deficit; 
FIGs. 7A and 7B appear unrelated to such a concept. Whether any entries remain in a segment 
of the slow wheel (720) and moving an LCD entry (722) do not appear to have any relation to 
how much a previously scheduled amount of data exceeded a threshold - especially since Delp 
cannot schedule more than one time slot's worth of data at a time. 



No new matter has been added with the preceding amendments. It is submitted that the 
application is in condition for allowance. Such action is respectfully requested. If prosecution of 
this application may be facilitated through a telephone interview, the Examiner is invited to 
contact Applicant's attorney identified below. 



Park, Vaughan & Fleming LLP 

702 Marshall Street, Suite 310 
Redwood City, CA 94063 
(650) 474-1973: voice 
(650) 474-1976: facsimile 
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Respectfully submitted. 



Date: February 27 . 2004 




